System and method for managing and updating information relating to economic entities

ABSTRACT

Methods and systems for managing and updating information relating to economic entities using sets of unique identifiers. A universe database contains record entries. Each of the record entries is associated with a unique universe identifier. A customer database contains customer record entries. Each customer record entry is associated with a unique customer identifier. A conversion table provides a mapping between the unique universe identifiers and the unique customer identifiers. The information contained in the customer database is updated using the unique universe identifiers, unique customer identifiers and the conversion table. The unique universe identifiers and the unique customer identifiers are stable over a period of time.

TECHNICAL FIELD

[0001] This invention relates to managing and updating a massive amountof information relating to economic entities and providing informationrequested by an information buyer to the information buyer, and, inparticular, to efficiently providing the requested information using twosets of unique identifiers.

BACKGROUND OF THE INVENTION

[0002] The present invention relates to managing and processing massiveamounts of information regarding virtually each and every participant intoday's economy. A significant part of today's economy relies oninformation provided by information suppliers, those who gather andprocess raw data and provide processed information regarding an economicentity to information buyers. As an example, an information suppliergathers data regarding a consumer and sells processed information to aninformation buyer. An information buyer uses the processed informationto identify potential customers of its products and to shape and targetits marketing strategies. Examples of information buyers include creditcompanies, retailers, manufacturers and service providers.

[0003] An information supplier provides information according tocriteria specified by an information buyer. One information buyer mayonly need addresses and names of its potential customers. Anotherinformation buyer may wish to know the type of food and clothing apotential customer prefers, in addition to the customer's name andaddress. A third information buyer may wish to know the potentialcustomer's marital status, income and assumed debts.

[0004] Traditional methods of supplying processed information are laborintensive and require tremendous processing capability and time. Ingeneral, traditional methods involve a step of comparing the content ofan information buyer's customer file to the content in the informationsupplier's file. Comparing data contents requires a batch processing andpresents a substantially difficult task. Information about a particularperson is often captured in various forms, requiring various steps tostandardize an information buyer's customer file. For example, even aperson's name may have been entered in the customer's files in three orfour different ways. In addition, the amount of information availableregarding an individual exploded with advancements made in computer andinformation technologies, presenting a daunting amount of information tobe handled and managed.

[0005] Traditional methods also often fragmented databases of aninformation buyer according to the buyer's business units andgeographical locations of the buyer's subunits. In other words, aninformation buyer's customer file was often stored in a fragmented way,thereby preventing the information buyer from having an integrated viewof its customers. A corporation cannot provide the most efficientservices to its customers when it only has fragmented views of itscustomers and cannot access all information it has regarding aparticular customer. For example, a regular customer of a corporationdoes not regard the corporation based on its different business unitsand is likely to be frustrated when a unit of the corporation cannotaccess the customer's file when the customer has been dealing for anumber of years with another unit of the corporation.

[0006] In addition, new digital infrastructures such as the Internet andwireless communications brought about capability to distributeinformation in an amazing speed to almost every location on the globe.Accordingly, customers of information buyers expect high qualityservices in near real-time. In turn, information buyers expectinformation suppliers to deliver high quality information in nearreal-time. At the same time, the digital revolution brought about vastcapability to gather astounding amounts of information regarding everyeconomically active person, either natural or legal. Information buyersexpect information suppliers to be able to gather, process and deliverenormous amounts of information in near real-time.

[0007] An information supplier such as Acxiom Corporation (“Acxiom”)attempts to meet the challenges in the digital age buy using a pluralityof persistent keys that link the record entries of information buyerswith the record entries in its central database. U.S. Pat. No. 6,073,140assigned to Acxiom, which patent is incorporated herein by thisreference, discloses an open system in which an information buyer'sdatabases are updated using a plurality of persistent keys and versionnumbers. A version number associated with a persistent key is updatedeach time the content in Acxiom's central database associated with thepersistent key is updated. An information buyer's database becomesupdated when the buyer's version number differs from the version numberin Acxiom's central database with respect to the same persistent key.

SUMMARY OF INVENTION

[0008] The present invention provides systems and methods for managingand updating massive amounts of information relating to economicentities. An information supplier's universe database includes recordentries, which are subject to change. Each record entry is associatedwith a unique universe identifier (“UUID”). A record entry can containall information regarding a particular economic entity, including, amongothers, the address, the telephone number, marital status and credithistory. A UUID is stable over time, thus can be used to link raw datagenerated by an economic entity and which raw data are subject tochange.

[0009] When an information buyer transfers its customer database to theinformation supplier to update its database, the supplier assigns a setof unique customer identifiers (“UCID's”) to each record entry in thecustomer's database. A UCID is assigned to each and every record entrycontained in the customer's database regardless of whether a recordentry corresponds to an existing economic entity. The UCID is stableover a period of time, and each of the customer record entries isorganized per person. Accordingly, each of the UCID's can be used tolink separate data generated over time regarding a particular customerof an information buyer.

[0010] The supplier also creates a conversion table or other desiredfunctionality for associating, mapping, linking, or correlating(hereinafter “associating”) the UCID's and UUID's. The supplier thenuses the UUID's, UCID's and the associating functionality to efficientlytransfer information desired by an information buyer and referenced by aUCID. The supplier assigns a set of UCID's per information buyer. Eachbuyer has its unique set of UCID's. Accordingly, integrity of data percustomer database belonging to an information buyer is facilitated.

[0011] An information supplier keeps track of enormous amounts ofinformation relating to virtually every economic entity generating rawdata within a defined universe. A UUID, which is preferably stable overtime, facilitates management of information by providing a way to linkseparate and modular data inputs regarding a particular economic entity.Similarly, a UCID, which is preferably stable over time, allows a way tolink different sets of information regarding a particular customer of aninformation buyer. A set of UCID's enables an information buyer to havean integrated view of each and every of its customers. Furthermore, theUCID's allow the information buyer to transmit only its UCID's or asubset thereof to the information supplier when the buyer wishes toupdate its customer record entries. Accordingly, the present inventionreduces the amount of data that needs to be handled or transmitted froman information buyer to an information supplier.

[0012] For certain time-critical information, the present inventionprovides a way to update such information in near real-time. Aninformation buyer can transmit via the Internet or a wirelesscommunication link, the UCID associated with the time-criticalinformation. The information supplier can find the corresponding UUIDusing the UCID and the associating functionality. The supplier canupdate the content requested by the buyer via the Internet or anotherreal-time communication link.

[0013] The use of two sets of unique identifiers provides a way todecouple the information buyer's customer file and the informationsupplier's universe file. This decoupling provides several advantages.Among them are that it prevents inadvertent contamination of informationbetween the customer database and the universe database. The universedatabase includes highly sensitive information, such as creditinformation and other regulated information. The decoupling provides aways to prudently control highly sensitive information. In addition, thedecoupling provides a way to protect against information theft. Thedecoupling also reduces the chance that one buyer will accidentallyobtain access to another buyer's information.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 is an overview of a preferred system embodiment of thepresent invention.

[0015]FIG. 2 is an exemplary embodiment of the initial transfer ofinformation from an information supplier to an information buyeraccording to the principles of the present invention.

[0016]FIG. 3 is an exemplary embodiment of a non-initial transfer ofinformation from an information supplier to an information buyeraccording to the principles of the present invention.

[0017]FIG. 4 is an exemplary embodiment of a transfer of informationrelating to a consumer referenced by a UCID and the corresponding UUID.

DETAILED DESCRIPTION

[0018] Referring to FIG. 1, an overview of an exemplary process 100involved in gathering, updating and processing information regarding aneconomic entity is described. An information supplier 102 keeps auniverse file (“UF”) 104 that can contain a record entry for each entitythat generates raw data in a universe X. For example, a universe X maycomprise the United States. The supplier gathers raw data relating toeach economic entity, 106A through 106ZZ. The supplier then processesthe raw data and stores the processed information relating to eacheconomic entity in universe X.

[0019] Each record entry for an economic entity can be associated with aunique universe identifier (“UUID”). The UUID is preferably stable overtime. In other words, all and every information concerning an entity canbe referenced and accessed by using a UUID associated with the entityregardless of time and geographical location. For example, if an entity106A installs a telephone line at time X and the entity assumes amortgage at a later time Y, the supplier can receive informationrelating to these events and both these events can be referenced usingthe same UUID. As another example, if the entity 106A buys a house inlocation Y and buy a car in location Z, the supplier can gatherinformation relating to these events and both of these events can bereferenced using the same UUID. A record entry can contain allinformation relating to an economic entity, including, among others, thename, address, telephone number, utility bill payment history and credithistory. A record entry can include a plurality of data files. The UUIDcan be assigned as appropriate, per economic entity, per record entry,or per any other desirable data trait. A preferred embodiment assignsthe UUID per entity.

[0020] The use of UUID's, which is preferably stable over a period oftime and assigned preferably per entity, facilitates management andintegration of information regarding an economic entity. Raw datarelating to an economic entity is subject to change. For example, aperson's address, name, telephone names, e-mail address, and maritalstatus may change over time. Furthermore, a person's certain traits maymanifest for a short time period then disappear. For example, a personmay become fanatical over chocolate ice cream and buy gallons of icecream every week, then develop a distaste for chocolate ice cream. Theperson may then develop another interest. The UUID's provide a way tolink all information relating to an entity regardless of time and space.They also provide a way to avoid fragmentation of information relatingto an entity. Similarly, the UUID's provide safeguards against loss ofinformation regarding an economic entity. All information regarding anentity can be integrated, analyzed and modeled to provide a holisticmarket benchmark for the particular person.

[0021] The supplier 102 provides information to a plurality ofinformation buyers, commonly designated as 108. For example, aninformation buyer 108 a may be a manufacturer of bicycles and may buy alist of customers who are potential buyers of bicycles. The supplierdelivers a customer file (“CF”) 120 a to the information buyer 108 a.Similarly, an information buyer 108 b may be a credit company and buy alist of customers who are potential consumers of its services. Thesupplier 102 delivers a CF 120 b to the information buyer 108 b.

[0022] In general, a CF includes a subset of the information included inthe UF. There are several reasons for this. An information buyer 108 amay be geographically limited and therefore not wish to obtaininformation on someone who is not residing in a specified locality.Another buyer may be interested in obtaining information regardingentities who are natural persons and are under the age of thirty-five(“35”). Yet another buyer may also be interested in only those entitieswhose behavior indicates that they would be good credit card customers.Still another buyer may need only parts of the information kept in theUF on each entity. In any event, the supplier identifies the content tobe delivered in a CF file according to the information buyer'sspecifications.

[0023] Each record entry in a CF can be assigned with a unique customeridentifier (“UCID”). A UCID can be assigned to every customer recordentry regardless of whether the record entry identifies an economicentity. For example, the CF 120 a may include old or corrupted data andthus include a record entry that may not correspond to an economicentity constituting a potential customer for the information buyer 108a. Regardless, a UCID can be assigned for each and every customer recordentry in a CF. A UCID is preferably stable over time. Accordingly, aUCID provides a way to link separate data inputs generated at differenttimes and at different locations and yet relating to the record entrycorresponding to the same UCID.

[0024] The supplier 102 can assign a different set of UCID's perinformation buyer. A set of UCID's used for a CF belonging to the buyer108A is, therefore, preferably different from a set of UCID's used for aCF belong to the buyer 108B. The use of different sets of UCID's perinformation buyer provides capability to protect proprietary informationbelonging to each information buyer. The use of different sets of UCID'salso provides capability to avoid unintended dilution or expansion ofinformation contained in a CF of a particular information buyer.Furthermore, using different sets of UCID's for different customersavoid the security issues and other numerous problems associated withthe previously discussed persistent key approach where different buyersare using the same key to access the same record entry. For example, thesupplier can change periodically a set of UCID's belonging to aninformation buyer, thereby providing an increased security forinformation contained in the buyer's CF.

[0025] Referring to FIGS. 2 and 3, a preferred embodiment fortransferring information from a supplier's universe file to a buyer'scustomer file is provided. The process depends on whether each recordentry in the customer file was previously assigned with a UCID. In FIGS.2 and 3, the universe file is illustrated as contained in a singledatabase. Similarly, the customer file is illustrated as contained in asingle database. Those skilled in the art will understand that theuniverse and customer files can be stored in several different databasesand memory devices located across different geographical areas. Therequirement is that a record entry corresponding to a UUID be accessibleregardless of the location and manner by which the record entry isstored. Similarly, a record entry corresponding to a UCID needs to beaccessible regardless of the location and manner by which the recordentry is stored. A record entry can include a plurality of data files.

[0026] Referring to FIG. 2, a process of transferring information whenan information buyer provides a customer file which does not havepreviously assigned UCID's is described. An information buyer 202provides its CF 204 to a supplier 206 to update record entries containedin the CF 204. In general, the buyer provides the CF 204 to the supplier206 using storage devices, such as magnetic tapes, CD's or DVD's.However, the CF 204 can be transferred to the supplier 206 via anycommunicational means, including wired and wireless communications, suchas satellite transmissions and the Internet.

[0027] In a preferred embodiment, information in the CF 204 is organizedper person. Accordingly, upon the receipt of the CF 204, the supplier206 checks to ascertain the information in CF 204 is organized perperson. If the content of the 204 is not organized per person, thesupplier reworks the content of the CF 204 such that the content becomesorganized per person. The element 208 represents a working customer file(“WCF”) whose record entry organization may or may not be the same asthat in the CF 204.

[0028] The supplier then matches or correlates the content of the WCF208 with the information contained in the UF 210. The process ofmatching information contained in two different databases is well knownin the art. For example, public domain identity data can be used tomatch the content of the WCF 208 with the content contained in the UF210. The result of the matching process, in general, will include amatched customer file (“MCF”) 212 and a non-matched customer file(“NMCF”) 214. The supplier then updates the content of the MCF 212according to the specifications of the information buyer 202.

[0029] The supplier assigns a UCID to each record entry in MCF, as wellas each record entry in NMCF 214. Those skilled in the art willunderstand that the assignment of the UCID's to the record entries inthe CF or files derived therefrom may occur at any time after the CF 204is delivered to the supplier and preferably before the supplier deliversan updated customer file (“UCF”) to the buyer 202. Those skilled in theart will also understand that the MCF 212 and NMCF 214 need not becombined before being delivered to the buyer 202 since the CF 204 may bestored in various formats as long as a UCID can be used for all relateddata identified as a single record entry.

[0030] After assigning a set of UCID's, the supplier creates aconversion table or other desired mapping, linking, associating, orcorrelating (hereinafter, “associating”) functionality to associate theUUID's and UCID's (hereinafter, “CT” or “conversion table”) 218. The CT218 can be used in subsequent transfers of information from the supplier206 to the buyer 202. The supplier 206 delivers an updated customer file(“UCF”) 216 to the buyer 202 via any viable communicational links.

[0031] Referring to FIG. 3, a non-initial transfer of information fromthe supplier 306 to buyer 302 is described. The buyer 302 delivers a CF304 to the supplier 306. Each record entry should have a correspondingUCID. Using the conversion table created during the initial transfer ofinformation, the supplier 306 can easily identify and update thoserecord entries in the UF corresponding previously matched recordentries. The record entries that have not been previously matched withinformation contained in the UF or record entries that do not haveassigned UCID's are matched using the traditional data matching processdescribed in connection with FIG. 2. Iterative transfers of informationbetween an information supplier and an information buyer will result inintegration of information contained in the buyer's customer files, andthe need to perform expensive traditional data matching process willeventually disappear.

[0032] Accordingly, each UCID has a corresponding UUID, that is allrecord entries in CF 304 will eventually have a corresponding entries inthe UF, and the CT 318 is used to translate the UCID's assigned to theCF 304 to the UUID's in the UF. Once the mapping between the content ofthe CF 304 and the content of the UF 310 is accomplished, the updatingof the content of the CF becomes a trivial process. For example, certaininformation contained in a record entry referenced by a UUID can besimply written over into the record entry referenced by thecorresponding UCID. In addition, the information buyer 302 may transmitto the supplier 306 only the UCID's corresponding to record entries thebuyer wishes to update. The supplier can supply only a portion of therecord entry referenced by the corresponding UUID's. The use of theUUID's, UCID's and CT can eliminate the need to transfer a massiveamount of data from an information buyer to an information supplier.

[0033] The use of two sets of unique identifiers, i.e., the UUID's forthe record entries in the UF and the UCID's for the record entries in aCF provides several advantages. First, it provides a decoupling functionthat helps to protect security and integrity of different sets ofdatabases. It provides safeguards against inadvertent dilution andcontamination of data between the UF and a CF. In addition, the UFcontains highly sensitive data, such as credit information andinformation subject to various federal or local laws. The use ofdifferent sets of identifiers for the UF and CF provides a way tocontrol and prudently manage sensitive and/or regulated information. TheUCID's cannot be used to ascertain credit or regulated information.Furthermore, an information thief cannot use a set of the UCID's to backtrace the source of information. In this sense, the CT acts as a filteror a gateway to isolate the outside world from the UF, unlike thepersistent key approach mentioned above.

[0034] The UF contains time-sensitive information. The supplier hasability to obtain economic transaction of a person in near real-timebasis. Each time a consumer generates an economic event, such as buyinga box of chocolates using a credit card, or assuming a mortgage, thesupplier has ability to update record entries in its UF. Certain aspectsof information regarding a person may be time critical to certaininformation buyers. The use of the UUID's, UCID's and CT allowscapability to provide critical information to an information buyer innear real-time.

[0035] Referring to FIG. 4, a transfer of information relating to aconsumer referenced by a UCID and the corresponding UUID is described. AUUID 404 references a record entry 420 containing information relatingto an entity 402. In general the record entry 420 includes a pluralityof data files, commonly designated as 406. When the entity 402 generatesevents, such as changing her residency and disconnecting her telephonenumber and utilities, an information supplier receives new raw dataregarding the entity 402. The supplier has ability to process the rawdata and recognize, for example, the data file 406 a containing theaddress for the person 402 needs to be updated. When the buyer 410 atransfers the UCID 412, the supplier finds the corresponding UUID 404using the conversion table 440. The supplier can also initiate transferof information regarding the entity 402 when certain informationregarded by the buyer 410 a to be time-critical becomes updated.

[0036] The data file 406 a is associated with a set of attributes,commonly designated as 408. For example, an attribute 408 a specifieswhether the data file 406 a is regulated or non-regulated. Anotherattribute 408 x specifies the time critical level of the data file 406 afor different information buyers. Depending on the attributes associatedwith the data file 406 a, the supplier can transfer in near real-timethe updated content of the data file 406 a to an information buyer. Forexample, the content of data file 406 a is non-regulated and timecritical to buyer 410 a. The supplier can use the UUID 404 and theconversion table 440 to find the corresponding UCID 412. The supplierthen can deliver the content of the data file 406 a to update thecorresponding data file 414 a contained in the record entry 430referenced by the UCID 412. The supplier can provide new time-criticalinformation to the buyer 410 a via any real-time methods ofcommunications, including the Internet and wireless communications.Those skilled in the art will understand that a supplier's computer canalso overwrite the content of the data file 406 a into the data file 414a associated in a buyer's computer using a standard protocol such asExtensible Markup Language (“XML”).

[0037] The foregoing is provided for purposes of explanation anddisclosure of preferred embodiments of the present invention. Furthermodifications and adaptations to the described embodiments will beapparent to those skilled in the art and may be made without departingfrom the spirit and scope of the invention and the following claims.

What is claimed is:
 1. A method for updating a customer file having aplurality of record entries, comprising: receiving raw datacorresponding to at least one event generating entity; processing theraw data and generating at least one processed record entry; storing aplurality of processed record entries in a universe database, eachrecord entry being associated with a unique universe identifier(“UUID”); comparing the content of the customer file with the content ofthe universe database; generating a matched customer file and anon-matched customer file; assigning a unique customer number (“UCID”)for each record entry contained in the customer file; associating eachUCID with a corresponding UUID; and updating a portion of at least onerecord entry in the matched customer file with information contained inthe processed record entry associated with the UUID corresponding to theUCID associated with the at least one record entry.
 2. The method ofclaim 1, wherein each UUID is stable over a period of time; and eachUCID is stable over another period of time, and the raw data is subjectto change.
 3. The method of claim 1, wherein a UCID is assigned to everyrecord entry contained in the customer file regardless of whether arecord entry corresponds to an existing economic entity.
 4. The methodof claim 1, wherein the action of comparing the content of the customerfile with the content of the universe database comprises organizing therecord entries in the customer file per person.
 5. The method of claim1, wherein the action of comparing the content of the customer file withthe content of the universe database comprises using public domainidentity data common to the customer file and the universe database. 6.The method of claim 1, wherein the action of associating each UCID witha corresponding UUID comprises: generating a conversion table providinga mapping between the UCID's with a set of the UUID's contained in theuniverse database.
 7. The method of claim 1, wherein the action ofupdating a portion of at least one record entry is accomplished using abatch mode.
 8. The method of claim 1, wherein the action of updating atleast a portion of at least one record entry is accomplished in nearreal-time via the Internet.
 9. A method for updating a customer filehaving a plurality of customer record entries, each customer recordentry being associated with a unique customer identifier (UCID),comprising: transferring a UCID contained in the customer file;associating the transferred UCID with a corresponding unique universeidentifier (UUID) referencing one record entry contained in aninformation supplier's database; and updating a portion of the customerrecord entry associated with the transferred UCID with informationcontained in the record entry referenced by the corresponding UUID. 10.The method of claim 9, wherein the record entry contains informationrelating to events generated by an economic entity; each UCID is stableover a period of time; and each UUID is stable over another period oftime.
 11. The method of claim 9, wherein the action of associating thetransferred UCID with the corresponding UUID comprises referencing aconversion table providing a mapping between a plurality of UCID's and aplurality of UUID's.
 12. The method of claim 9, wherein the action ofupdating a portion of the customer record entry associated with thetransferred UCID comprises a batch processing mode.
 13. The method ofclaim 9, wherein the action of transferring a UCID comprises a transferof data via the Internet.
 14. The method of claim 9, wherein the actionof transferring a UCID comprises a transfer of data via a wirelesscommunication link.
 15. The method of claim 9, wherein the action ofupdating a portion of the customer record entry associated with thetransferred UCID comprises a transfer of data via the Internet.
 16. Themethod of claim 9, wherein the action of updating a portion of thecustomer record entry associated with the transferred UCID comprises atransfer of data via a wireless communication link.
 17. The method ofclaim 9, comprising: updating the transferred UCID with a new UCID;associating the new UCID with a UUID; and generating a conversion tableproviding a mapping between the new UCID and the UUID associated withthe new UCID.
 18. A method for updating a customer file having aplurality of customer record entries, each customer record entry beingassociated with a unique customer identifier (UCID), comprising:transferring a UCID to an information supplier, the supplier having auniverse database containing record entries, each of said record entrybeing associated with a unique universe identifier (“UUID”); associatingthe transferred UCID with a corresponding UUID; and updating a portionof the customer record entry associated with the transferred UCID withinformation contained in the record entry being associated with thecorresponding UUID.
 19. The method of claim 18, wherein each of therecord entries comprises processed information from raw datacorresponding to events generated by an economic entity.
 20. The methodof claim 18, wherein the action of transferring a UCID is accomplishedvia the Internet.
 21. The method of claim 18, wherein the action oftransferring a UCID is accomplished via a wireless communication link.22. The method of claim 18, wherein the action of transferring a UCID isaccomplished via a wired communication link.
 23. The method of claim 18,wherein the action of updating a portion of the customer entryassociated with the transferred UCID comprises a batch processing. 24.The method of claim 18, wherein the action of updating a portion of thecustomer entry associated with the transferred UCID comprises a transferof data via a wired communication link.
 25. The method of claim 18,wherein the action of updating a portion of the customer entryassociated with the transferred UCID comprises a transfer of data via awireless communication link.
 26. The method of claim 18, wherein eachUCID is stable over a period time and each UUID is stable over anotherperiod of time.
 27. The method of claim 18, comprising: changing thetransferred UCID to a new UCID, associating the new UCID with a UUID;and generating a conversion table providing a mapping between the newUCID and the UUID associated with the new UCID.
 28. A system forupdating a plurality of customer files, each of said customer filesbelonging to an information buyer, comprising: a universe databasecontaining record entries, each record entry being associated with aunique universe identifier (“UUID”); a means for assigning a set ofunique customer identifiers (“UCID”) for each of the customer files; aconversion table providing a mapping between a set of the UUID's andeach set of the UCID's assigned to each of the plurality of customerfiles; and updating a portion of at least one customer file using atleast one UCID in the set of the UCID's corresponding to the least onecustomer file and a portion of the conversion table.
 29. The system ofclaim 28, wherein each set of the UCID's is different from another setof the UCID's.
 30. The system of claim 28, wherein the conversion tablecomprises a plurality of customer conversion tables, each customerconversion table corresponding to one of the plurality of customer filesand providing a mapping between a set of UUID's and the set of UCID'sassigned for the corresponding customer file.
 31. The system of claim28, wherein the record entries contained in the universe databasecorrespond to economic entities; each UUID is stable over a period oftime; and each UCID is stable over another period of time.
 32. Thesystem of claim 28, wherein at least one set of UCID's is changed to anew set of UCID's, each UCID in the new set being associated with aUUID; and a conversion table provides a mapping between the new set ofUCID's and a set of the UUID's.
 33. A system for updating a customerdatabase containing a plurality of customer record entries, eachcustomer record entry being associated with a unique customer identifier(“UCID”), comprising: a universe database containing record entries,each record entry being associated with a unique universe identifier(“UUID”); a conversion table providing a mapping between the UUID's andUCID's; and updating a portion of the customer database with informationcontained in the universe database using the UUID's, the conversiontable and the UCID's.
 34. The system of claim 33, wherein the UUID's arestable over a period of time and the UCID's are stable over anotherperiod of time.
 35. The system of claim 33, wherein the UCID's areupdated with a new UCID's and a new conversion table provides a mappingbetween the UUID's and UCID's.
 36. A method for managing informationrelating to event generating entities, comprising: receiving raw datagenerated by the entities; processing the raw data and generatingprocessed record entries, each record entry being associated with aunique universe identifier (“UUID”), receiving a customer databasecontaining a plurality of customer record entries; and assigning aunique customer identifier (“UCID”) for each of the customer recordentries; and creating a conversion table providing a mapping for eachUCID to one and only corresponding UUID.
 37. The method of claim 36,wherein each UUID is stable over a period of time; each UCID is stableover another period of time.
 38. The method of claim 36, wherein aportion of the customer database is updated using the UUID's, UCID's andthe conversion table.
 39. A method for managing information relating toevent generating entities, comprising: receiving raw data generated bythe entities; processing the raw data and generating processed recordentries, each record entry being associated with a unique universeidentifier (“UUID”); receiving at least one unique customer identifier(“UCID”); and updating a portion of the customer database using aconversion table providing a mapping of the at least one UCID to acorresponding UUID.
 40. The method of claim 39, wherein each UUID isstable over a period of time; each UCID is stable over another period oftime.
 41. The method of claim 39, wherein the received UCID is changedwith a new UCID and the conversion table provides a mapping between thenew UCID and a UUID.
 42. A method for managing information relating toan event generating entity, comprising: receiving raw data generated bythe entity; processing the raw data and generating at least one datafile being accessible by a unique universe identifier (“UUID”); findinga corresponding unique universe customer identifier (“UCID”) using aconversion table; transferring the at least one data file to update arecord entry being associated with the UCID.
 43. The method of claim 42,wherein the action of transferring the at least one data file occursafter determining the state of an attribute associated with the at leastone data file.
 44. The method of claim 42, wherein the UUID is stableover a period of time and the UCID is stable over another period oftime.
 45. A system for managing information relating to an eventgenerating entity, comprising: a record entry comprising a plurality ofdata inputs, the record entry being associated with a unique universeidentifier (“UUID”); a customer record entry comprising a plurality ofcustomer data inputs, the customer record entry being associated with aunique customer identifier (“UCID”); a conversion table providing amapping between the UUID and UCID; and updating a portion of thecustomer record entry using the UUID, UCID and conversion table.
 46. Thesystem of claim 45, wherein the UUID is stable over a period of time andthe UCID is stable over another period of time.
 47. The system of claim45, wherein each of the plurality of customer data inputs is associatedwith an attribute and the action of updating a portion of the customerrecord entry occurs in response to determining the state of theattribute associated with at least one of the plurality of customer datainputs.
 48. A method for updating a plurality of customer files, eachcustomer file having a plurality of record entries, comprising:receiving raw data corresponding to at least one event generatingentity; processing the raw data and generating at least one processedrecord entry; storing a plurality of processed record entries in auniverse database; each record entry being associated with a uniqueuniverse identifier (“UUID”); comparing the content of each of theplurality of customer files with the content of the universe database;generating a matched customer file and a non-matched customer file foreach of the plurality of customer files; assigning a set of uniquecustomer identifiers (“UCID's”) for each customer file, each UCID withinthe set being associated with each record entry contained in thecustomer file corresponding to the set of UCID's; associating each UCIDwith a corresponding UUID; and updating a portion of at least one recordentry in at least one matched customer file with information containedin the processed record entry associated with the UUID corresponding tothe UCID associated with the at least one record entry.
 49. The methodof claim 48, wherein each UUID is stable over a period of time; and eachUCID is stable over another period of time.
 50. The method of claim 48,wherein a UCID is assigned to every record entry contained in each ofthe plurality of customer files regardless of whether a record entrycorresponds to an existing economic entity.
 51. The method of claim 48,wherein the action of associating each UCID with a corresponding UUIDcomprises: generating a conversion table for each of the plurality ofcustomer files, each conversion file providing a mapping between the setof UCID's assigned to the corresponding customer files with a set of theUUID's contained in the universe database.
 52. The method of claim 48,wherein the action of updating a portion of at least one record entry isaccomplished using a batch mode.
 53. The method of claim 48, wherein theaction of updating at least a portion of at least one record entry isaccomplished in near real-time via the Internet.